1. Field
The present disclosure relates to UDDI Registry and Web Services in general, and in particular to method(s), apparatus and system(s) used in giving practical effect to such services.
2. Description of Related Art
UDDI (Universal Description, Discovery and Integration) is a set of Standards that have been defined to enable applications that use Web Services to quickly, easily and dynamically interact with one another. UDDI is intended to create a platform-independent, open framework for describing services, discovering businesses and integrating system services using the Internet, as well as an operational registry.
A UDDI registry provides valuable support to systems structured using Web Services. FIG. 1a illustrates schematically basic Web Services and UDDI concepts. FIG. 1b illustrates schematically a simplified protocol stack for the Web Services environment. UDDI provides a repository for Web Services information and is itself provided by way of a Web Service.
UDDI enables applications to publish how they want to interact on the web. Each ‘Web Service’ is a self-describing, self-contained, modular unit of application logic that provides some system functionality to other applications through an Internet connection. Applications access Web Services via ubiquitous web protocols and data formats, with no need to worry about how each Web Service is implemented. Web Services can be mixed and matched with other Web Services to execute a larger workflow or business transaction.
The UDDI Standards describe a specific-purpose repository that is intended to manage descriptions of Web Service types, business organizations, and details about how to invoke the Web Services. The Standards do not necessarily specify how the Standards should be implemented, nor whether the implementation should include storage using a database, a Directory or any other medium.
At a web site hosted by the organisation responsible for the UDDI Standards there are a number of Frequently Asked Questions (FAQ). One of these questions is: “Can a UDDI registry be built or based on LDAP?” In answer, this web site discloses that there is no formal relationship between UDDI and Directories. “The UDDI specification does not dictate registry implementation details. The UDDI specification defines an XML-based data model and a set of SOAP APIs to access and manipulate that data model. The SOAP APIs define the behaviour a UDDI repository exhibits. A UDDI implementation could be built on an LDAP Directory as long as it conforms to the specified behaviour. Thus far, all UDDI implementations have been built on relational databases.”
It is to be noted that Directory technologies, such as X.500 and LDAP, are extensible, general-purpose data stores and their associated languages that are most often used to manage users and resources. They are very well established technologies, widely adopted, and considered very stable and reliable.
However, implementing the UDDI Standards on a Directory requires the solving of a number of problems. The UDDI Standards leave many important issues unaddressed, such as:                The UDDI Standard defines a number of objects, some of which are related by a hierarchy, but UDDI does not define an all-encompassing hierarchy. For example. Business Service objects will come under Business Entity objects, and the Binding Template objects will come under Business Services. FIG. 2 illustrates an example of this hierarchy. Business Entity objects are denoted 21, Business Services objects are denoted 22, and Binding Template objects are denoted 23. It is also to be noted that TModel objects, denoted 24, for example, are not hierarchically related to these objects. There are also other concepts such as Publisher Assertions, for example, which are not defined hierarchically.        creating an efficient implementation of the requirement that a user be permitted to alter only those objects under his/her control,        creating an efficient implementation that would allow UDDI registries to be distributed,        creating an efficient implementation which enhances aspects of management and performance of searching and update.        How to represent complex UDDI objects in a relatively efficient way. For example Business Entity, Business Service, Binding Template and/or TModel have compound repeating elements. In turn these repeating elements could contain further repeating elements. For example, a Business Entity may contain contacts and the contacts may contain addresses. Addresses may contain address lines and phone numbers. FIG. 13 illustrates schematically a UDDI concept of a relatively complex object in a Business Entity. The Business Entity object 131, includes, for example a number of attributes 132, such as AuthorizedName, BusinessKey, and Name. The Name has one or more Name fields 133, such as ‘text’ or this may be implicit in the ‘Name’ itself. There is also ‘language’. There may be one or more of these fields 133.        How to provide for relatively rapid searching for a specific items contained in repeating elements.        How to represent UDDI information and requirements in hierarchy of Directory objects,        How to manage deletion of UDDI objects and all their related information in an efficient manner, and        How to optimize construction of intermediate search result collections during search operations so that both Directory access and iterative in-memory operations are minimized, taking into account the Directory storage medium limitations. In practice, Directory entries may be stored and returned in arbitrary order, and Directory results may be too large to sort.        How to represent the data concerning a Publisher Assertion, in an efficient way,        How to create an efficient implementation of Publisher Assertions, particularly with regard to the implementation of the findrelatedBusiness method,        How to implement efficient searching of Publisher Assertions by relationship,        How to manage the validity of a Publisher Assertion,        How to restrict the assertions created and deleted for a Business Entity are made by the owner of a Business Entity.        How to efficiently manage related collections of attributes, as defined in the UDDI standard,        How to define attributes and objects to enhance the performance of searching.        
Various UDDI Schema have been proposed. However, none are considered to address at least the problems noted above. For example, one schema provides a relatively simplistic mapping of UDDI objects to Directory objects, without necessarily having regard to the complexities and optimization to produce an efficient commercial implementation. It is also unclear how a number of the UDDI services (the find_series, in particular) can be implemented efficiently in such a schema.
For example, FIG. 14 illustrates schematically a Novell representation of a relatively complex object in a Business Entity. The Business Entity object 141, includes for example a number of attributes 142, each having a ‘type’ and ‘value’. As illustrated, there is AuthorizedName having a value ‘Bill’, BusinessKey having a value ‘890.obale.890 . . . ’, and Name having multi-values 143, 144 namely                en# CA        IN# CATS        
The UDDI (FIG. 13) and Novell (FIG. 14) example representations are not considered to be efficient representations for Web Services.
Thus, there is a need to address the general problems noted above as well as other problems to provide a relatively extensible, efficient and reliable implementation of UDDI based on a Directory.